Request routing management based on network components

ABSTRACT

Systems and methods for managing requesting routing functionality associated with resource requests for one or more resources associated with a content provider are provided. A content delivery network (“CDN”) service provider, on behalf of a content provider, can process domain name service (“DNS”) requests for resources by computing devices and resolve the DNS requests by the identification of a network address of a computing device that will provide the requested resources. Based on the processing of DNS queries initiated by a client computing device, the CDN service provider can measure CDN service provider latencies associated with the generation of DNS requests by network components associated with the client computing devices. Examples of the network components can include DNS resolvers associated with the client computing device.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/071,276, entitled REQUEST ROUTING MANAGEMENT BASED ON NETWORKCOMPONENTS and filed on Nov. 4, 2013, which in turn is a continuationU.S. patent application Ser. No. 12/892,880, now U.S. Pat. No.8,577,992, entitled REQUEST ROUTING MANAGEMENT BASED ON NETWORKCOMPONENTS and filed on Sep. 28, 2010, the disclosures of each of whichare incorporated herein by reference.

BACKGROUND

Generally described, computing devices and communication networks can beutilized to exchange information. In a common application, a computingdevice can request content from another computing device via thecommunication network. For example, a user at a personal computingdevice can utilize a software browser application to request a Web pagefrom a server computing device via the Internet. In such embodiments,the user computing device can be referred to as a client computingdevice and the server computing device can be referred to as a contentprovider.

Content providers are generally motivated to provide requested contentto client computing devices often with consideration of efficienttransmission of the requested content to the client computing deviceand/or consideration of a cost associated with the transmission of thecontent. For larger scale implementations, a content provider mayreceive content requests from a high volume of client computing deviceswhich can place a strain on the content provider's computing resources.Additionally, the content requested by the client computing devices mayhave a number of components, which can further place additional strainon the content provider's computing resources.

With reference to an illustrative example, a requested Web page, ororiginal content, may be associated with a number of additionalresources, such as images or videos, which are to be displayed with theWeb page. In one specific embodiment, the additional resources of theWeb page are identified by a number of embedded resource identifiers,such as uniform resource locators (“URLs”). In turn, software on theclient computing devices typically processes embedded resourceidentifiers to generate requests for the content. Often, the resourceidentifiers associated with the embedded resources reference a computingdevice associated with the content provider such that the clientcomputing device would transmit the request for the additional resourcesto the referenced content provider computing device. Accordingly, inorder to satisfy a content request, the content provider would provideclient computing devices data associated with the Web page as well asthe data associated with the embedded resources.

Some content providers attempt to facilitate the delivery of requestedcontent, such as Web pages and/or resources identified in Web pages,through the utilization of a content delivery network (“CDN”) serviceprovider. A CDN service provider typically maintains a number ofcomputing devices in a communication network that can maintain contentfrom various content providers. In turn, content providers can instruct,or otherwise suggest to, client computing devices to request some, orall, of the content provider's content from the CDN service provider'scomputing devices.

As with content providers, CDN service providers are also generallymotivated to provide requested content to client computing devices oftenwith consideration of efficient transmission of the requested content tothe client computing device and/or consideration of a cost associatedwith the transmission of the content. Accordingly, CDN service providersoften consider factors such as latency of delivery of requested contentin order to meet service level agreements or to generally improve thequality of delivery service. Additionally, in embodiments in whichcomputing devices utilize an Internet service provider (“ISP”) toprovide connectivity, the CDN service provider can consider additionalfactors associated with the interaction between the CDN serviceprovider, client computing and ISP devices, such as a DNS resolvercomponent.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing aspects and many of the attendant advantages of thisinvention will become more readily appreciated as the same become betterunderstood by reference to the following detailed description, whentaken in conjunction with the accompanying drawings, wherein:

FIG. 1 is a block diagram illustrative of content delivery environmentincluding a number of client computing devices, a content provider, anda content delivery network service provider;

FIG. 2 is a block diagram of the content delivery environment of FIG. 1illustrating the registration of a content provider with a CDN serviceprovider;

FIG. 3 is a block diagram of the content delivery environment of FIG. 1illustrating the generation of resource requests by a client computingdevice;

FIG. 4 is a block diagram of the content delivery environment of FIG. 1illustrating the generation of DNS queries by a client computing devicecorresponding to embedded resources by a client computing device;

FIG. 5 is a block diagram of the content delivery environment of FIG. 1illustrating the generation of DNS queries by a client computing devicecorresponding to alternative identifiers by a client computing device;

FIG. 6 is a block diagram of the content delivery environment of FIG. 1illustrating the transmission of DNS queries by a client computingdevice in accordance with a network routing scheme by a client computingdevice;

FIG. 7 is a block diagram of the content delivery environment of FIG. 1illustrating the transmission of DNS queries by a client computingdevice in accordance with an alternative network routing scheme by aclient computing device;

FIG. 8 is a block diagram of the content delivery environment of FIG. 1illustrating the transmission of DNS queries by a client computingdevice in accordance with an alternative network routing scheme by aclient computing device; and

FIG. 9 is a flow diagram illustrative of a request routing processingroutine implemented by a service provider.

DETAILED DESCRIPTION

Generally described, the present disclosure is directed to managingrequest routing functionality associated with resource requests for oneor more resources associated with a content provider. Specifically,aspects of the disclosure will be described with regard to themanagement and processing of request routing functionality by a serviceprovider, such as a content delivery network (“CDN”) service provider,on behalf of a content provider. Illustratively, the request routingfunctionality can correspond to the processing of domain name service(“DNS”) requests for resources by computing devices and the resolutionof the DNS requests by the identification of a network address of acomputing device that will provide the requested resources. Based on theprocessing of DNS queries initiated by a client computing device, theCDN service provider can measure CDN service provider performancemeasurement information associated with the generation and processing ofDNS requests by network components associated with the client computingdevices. Examples of the network components can include DNS resolversassociated with the client computing device. Additionally, examples ofperformance measurement information can include the measurement oflatencies associated with transmitting and processing the DNS queries,data packet loss associated with the transmittal of the DNS queries,data throughput associated with the transmittal of the DNS queries,available bandwidth associated with a communication channel and thelike.

Although various aspects of the disclosure will be described with regardto illustrative examples and embodiments, one skilled in the art willappreciate that the disclosed embodiments and examples should not beconstrued as limiting. For example, the present disclosure may bedescribed with regard to request routing services provided by a serviceprovider, such as a CDN service provider, that may provide additionalservices and functionality including network-based storage services,caching services, application hosting, or other services. However, oneskilled in the relevant art will appreciate that a service provider neednot provide all, or any, of the additional services or functionalitythat may be associated with some service providers, such as a CDNservice provider.

FIG. 1 is a block diagram illustrative of content delivery environment100 for the managing registration of a content provider with a serviceprovider, such as a CDN service provider, and subsequent processing ofat least a portion of content requests on behalf of the contentprovider. As illustrated in FIG. 1, the content delivery environment 100includes a number of client computing devices 102 (generally referred toas clients) for requesting content from a content provider 104, anetwork storage provider, and/or a CDN service provider 106. In anillustrative embodiment, the client computing devices 102 can correspondto a wide variety of computing devices including personal computingdevices, laptop computing devices, hand-held computing devices, terminalcomputing devices, mobile devices, wireless devices, various electronicdevices and appliances and the like. In an illustrative embodiment, theclient computing devices 102 include necessary hardware and softwarecomponents for establishing communications over a communication network112, such as a wide area network or local area network. For example, theclient computing devices 102 may be equipped with networking equipmentand browser software applications that facilitate communications via theInternet or an intranet.

Illustratively, at least some of the client computing devices 102utilize a DNS resolver component 108, such as a DNS name server, thatreceives DNS queries from a client computing device 102 and thengenerates the DNS queries attributed to the client computing device, oron behalf of the client computing device. In one embodiment, the DNSresolver component 108 may be a local DNS component provided by anenterprise network to which the client computing device 102 belongs. Inanother embodiment, the local DNS resolver component 108 may be providedby an Internet Service Provider (“ISP”) that provides the communicationnetwork connection to the client computing device 102. In embodiments inwhich the client computing devices 102 utilize a DNS resolver component108, one skilled in the relevant art will appreciate that the DNSqueries generated on behalf of the client computing devices would beassociated with the IP address of the DNS resolver component 108 inaccordance with traditional networking protocols. In furtherembodiments, a client computing device 102 may be associated withmultiple DNS resolver components 108, such as a multi-tiered hierarchyof DNS resolver components. For example, a client computing device 102may be associated with a first DNS resolver component 108 provided by anenterprise network, which in turn is in communication with one or moreDNS resolver components provided by an ISP. In other examples, a singlenetwork provider may make multiple DNS resolver components 108 availableor responsive to the client computing device 102 DNS queries.

The content delivery environment 100 can also include a content provider104 in communication with the one or more client computing devices 102via the communication network 110. The content provider 104 illustratedin FIG. 1 corresponds to a logical association of one or more computingdevices associated with a content provider. Specifically, the contentprovider 104 can include a web server component 112 corresponding to oneor more server computing devices for obtaining and processing requestsfor content (such as Web pages) from the client computing devices 102.The content provider 104 can further include an origin server component114 and associated storage component 116 corresponding to one or morecomputing devices for obtaining and processing requests for networkresources. One skilled in the relevant art will appreciate that thecontent provider 104 can be associated with various additional computingresources, such additional computing devices for administration ofcontent and resources and the like. Additionally, although the originserver component 114 and associated storage component 116 are logicallyassociated with the content provider 104, the origin server component114 and associated storage components 116 may be geographicallydistributed throughout the communication network 112 in a manner to bestserve various demographics of client computing devices 102.

Although not illustrated in FIG. 1, the content provider 104 can beassociated with a number of additional or supplement components tofacilitate interaction with client computing devices 102 or serviceproviders. For example, a content provider 104 may maintain one or moreDNS name server components that are operative to receive DNS queriesrelated to registered domain names associated with the content provider104. The one or more DNS name servers can be authoritative to resolveclient computing device DNS queries corresponding to the registereddomain names of the content provider 104. The content provider 104 canalso maintain additional storage components, such as proxy servers, orutilize network storage service providers to maintain at least a portionof the content/resources provided to the client computing devices 102.

With continued reference to FIG. 1, the content delivery environment 100can further include a service provider, generally referred to as the CDNservice provider 106, in communication with the one or more clientcomputing devices 102 and the content provider 104 via the communicationnetwork 110. The CDN service provider 106 illustrated in FIG. 1corresponds to a logical association of one or more computing devicesassociated with a service provider. Specifically, the CDN serviceprovider 106 can include a number of Point of Presence (“POP”) locations118, 124 that correspond to nodes on the communication network 110. EachPOP 118, 124 includes a DNS component 120, 126 made up of a number ofDNS server computing devices for resolving DNS queries from the clientcomputers 102. Each POP 118, 124 also optionally includes a resourcecache component 122, 128 made up of a number of cache server computingdevices for storing resources from content providers or network storageproviders and transmitting various requested resources to various clientcomputers 102. The DNS components 120, 126 and the resource cachecomponents 122, 128 may further include additional software and/orhardware components that facilitate communications, including, but notlimited to, load balancing or load sharing software/hardware components.

Still further, the CDN service provider 106 can include additional datastores for managing request routing information. Specifically, in anillustrative embodiment, the CDN service provider 106 can include a DNSresolver log data store 130 for maintaining information regarding DNSqueries provided by the DNS resolvers 108 on behalf of client computingdevices 102. As previously described, examples of performancemeasurement information can include latency information, data packetloss information, data throughput information, available bandwidthassociated with a communication channel, and the like. Additionally, theDNS resolver log data can further include performance measurementinformation or other information associated with the transmittal orprocessing of DNS queries. Although the DNS resolver log data store 130is illustrated as a single, centrally located data store, one skilled inthe relevant art will appreciate that the DNS resolver log data store130 may be distributed among several data stores or be maintained, atleast in part, among the POPs 118, 124.

In an illustrative embodiment, the DNS component 120, 126 and resourcecache component 122, 128 are considered to be logically grouped,regardless of whether the components, or portions of the components, arephysically separate. Additionally, although the POPs 118, 124 areillustrated in FIG. 1 as logically associated with the CDN serviceprovider 106, the POPs will be geographically distributed throughout thecommunication network 110 in a manner to best serve various demographicsof client computing devices 102. Additionally, one skilled in therelevant art will appreciate that the CDN service provider 106 can beassociated with various additional computing resources, such asadditional computing devices for administration of content andresources, and the like. Even further, the components of the CDN serviceprovider 106 can be managed by the same or different entities. Oneskilled in the relevant art will also appreciate that the components andconfigurations provided in FIG. 1 are illustrative in nature.Accordingly, additional or alternative components and/or configurations,especially regarding the additional components, systems and subsystemsfor facilitating communications may be utilized.

With reference now to FIGS. 2-8, the interaction between variouscomponents of the content delivery environment 100 of FIG. 1 will beillustrated. For purposes of the example, however, the illustration hasbeen simplified such that many of the components utilized to facilitatecommunications are not shown. One skilled in the relevant art willappreciate that such components can be utilized and that additionalinteractions would accordingly occur without departing from the spiritand scope of the present disclosure.

With reference to FIG. 2, an illustrative interaction for the optionalregistration of a content provider 104 with the CDN service provider 106for hosting content on behalf of the content provider 104 will bedescribed. As illustrated in FIG. 2, the CDN service provider contentregistration process begins with registration of the content provider104 with the CDN service provider 106. In an illustrative embodiment,the content provider 104 utilizes a registration application programinterface (“API”) to register with the CDN service provider 106 suchthat the CDN service provider 106 can provide content on behalf of thecontent provider 104, or at least perform the processes describedherein. Illustratively, the registration API can include theidentification of the origin server 114 of the content provider 104 thatmay provide requested resources to the CDN service provider 106. Inaddition or alternatively, the registration API can include the contentto be stored by the CDN service provider 106 on behalf of the contentprovider 104. Additionally, the content provider 104 can specify one ormore network storage providers (not illustrated) that may act as anorigin server for the content provider 104.

The CDN service provider 106 returns the embedded resource identifiersto the content provider 104 along with any additional information. Inturn, the content provider 104 can then store the embedded resourceidentifiers for embedding in requested content or otherwise embed (orassociate) the embedded resource identifiers with requested content(such as Web page markup language), which are described in greaterdetail below. In an illustrative embodiment, the embedded resourceidentifiers can be applicable to multiple content providers 104.Alternatively, the embedded resource identifiers can be unique to eachparticular content provider 104. Still further, the CDN service provider106 may provide additional logic to the content providers 104 thatcontrols the circumstances and/or methodologies for embedding theembedded resource identifiers into content. For example, the embeddedresource identifiers can include instructions (or executable code) thatdefines the type of content (e.g., specific Web pages) for which theembedded resource identifiers will apply.

With reference now to FIG. 3, after completion of the registration andembedding processes illustrated in FIG. 2, a client computing device 102generates a content request that is received and processed by thecontent provider 104, such as through the Web server 112. In accordancewith an illustrative embodiment, the request for content can be inaccordance with common network protocols, such as the hypertext transferprotocol (“HTTP”). Upon receipt of the content request, the contentprovider identifies the appropriate responsive content. In anillustrative embodiment, the requested content can correspond to a Webpage that is displayed on the client computing device 102 via theprocessing of information, such as hypertext markup language (“HTML”),extensible markup language (“XML”), and the like. The requested contentcan also include a number of embedded resource identifiers thatcorrespond to resource objects that should be obtained by the clientcomputing device 102 as part of the processing of the requested content.The embedded resources can correspond to multi-media content, such asimages, videos, text, etc. that will be processed by the clientcomputing devices 102 and rendered on an output device. Although notillustrated in FIG. 3, the client computing device 102 would first issuea DNS query for the content provided by the content provider 104, whichif properly resolved, would include the identification of the abovementioned IP address associated with the content provider. One skilledin the relevant art will appreciate that the resolution of the DNS querymay involve multiple DNS queries to either the content provider 104 orother service provider.

Generally, the identification of the embedded resources provided by thecontent provider 104 will be in the form of resource identifiers thatcan be processed by the client computing device 102, such as through abrowser software application. In an illustrative embodiment, theresource identifiers can be in the form of a uniform resource locator(“URL”). For purposes of an illustrative example, the URL can identify adomain of the CDN service provider 106 (e.g., CDNserviceprovider.com), aname of a resource to be requested (e.g., “resource.xxx”) and a pathwhere the resource will be found (e.g., “path”). Additionally, in anillustrative embodiment, the URL can also include one or more labelsthat include additional information utilized by the CDN service provider106 in the request routing process (e.g., “additional_information”).Examples of the additional information can include client computingdevice identifiers, user account identifiers, geographic identificationinformation, POP identifiers, DNS resolver performance measurementidentification information, and the like. In this illustrative example,the URLs of the embedded resource have the form of:

http://additional_information.CDNserviceprovider.com/path/resource.xxx

With reference now to FIG. 4, upon receipt of the requested content,including the embedded resource identifiers provided by the CDN serviceprovider 106, the client computing device 102 would first transmit a DNSquery through its DNS resolver 108 to request an IP address of acomputing device corresponding to the unique identifier provided by theCDN service provider 106. In accordance with traditional request routingprinciples, the DNS query would be received by the DNS resolver 108 andthen transmitted on behalf of the requesting client computing device102.

By way of example, in accordance with traditional DNS request routingprinciples, a DNS query for the URLhttp://additional_information.CDNserviceprovider.com/path/resource.xxxwould first include the identification of a DNS server authoritative tothe “.” and the “com” portions of the URL to the DNS resolver 108. Theissuance of DNS queries corresponding to the “.” and the “com” portionsof a URL are well known and have not been illustrated. After partiallyresolving the modified URL according to the “.” and “com” portions ofthe URL, the DNS resolver 108 then issues another DNS query for theresource URL that results in the identification of the DNS servercorresponding to the “.CDNserviceprovider” portion of the URL, asillustrated in FIG. 4, illustrated as the DNS server component 120 ofPOP 118.

The receiving DNS server component 120 obtains the DNS query from theDNS resolver component 108 and processes the DNS query. In anillustrative embodiment, the DNS server component 120 determines thatthe processing of the DNS query should be, at least in part, used tomeasure performance of the DNS resolver 108 or other network component.In one embodiment, the DNS query may not correspond to an actualresource that will be delivered to the client computing device 102. Inthis embodiment, the resolution of the DNS query may result in noresponse from a DNS server. In another embodiment, the resolution of theDNS query may result in the generation of additional actions/responsesfrom the DNS server for purposes of performance measurement.

Alternatively, the DNS query may correspond to an actual resourceprovided by the CDN service provider 106 on behalf of the contentprovider 104. Illustratively, the “additional_information” portion ofthe URL may include information that will be utilized to determinewhether the CDN service provider 106 should utilize the DNS query forperformance measurement or will be utilized in the determination of theperformance measurement. For example, a client computing device mayexecute a script prior to the generation of the DNS query that modifiesthe URL to include various identifiers or timing information to the URL.

To facilitate the performance measurement, the receiving POP, POP 118,can obtain information from the DNS query or collect additionalinformation. The collected information can be maintained in the DNSresolver log data store 130. One skilled in the relevant art willappreciate, that typically, a receiving DNS server can resolve DNSqueries by identifying an IP address of a cache server component, suchresource cache component 122, that will process the request for therequested resource. The selected resource cache component can processthe request by either providing the requested resource if it isavailable or attempting to obtain the requested resource from anothersource, such as a peer cache server computing device or the originserver 114 of the content provider 104. However, in this illustrativeembodiment, as an alternative to selecting a cache server component, theCDN service provider 106 can maintain sets of various alternativeresource identifiers that can be utilized for more refined requestrouting purposes. Additionally, in this embodiment, the alternativeresource identifiers can be utilized to measure the performance of theDNS resolver component 108 (or other network components). Specifically,the alternative resource identifiers can be provided by the CDN serviceprovider 106 to the client computing device 102 such that a subsequentDNS query on the alternative resource identifier will resolve to adifferent DNS server component within the CDN service provider'snetwork.

In an illustrative embodiment, the alternative resource identifiers arein the form of one or more canonical name (“CNAME”) records. In oneembodiment, each CNAME record identifies a domain of the CDN serviceprovider 106 (e.g., “cdnprovider.com” or “cdnprovider-1.com”). As willbe explained in greater detail below, the domain in the CNAME does notneed to be the same domain found in original URL or in a previous CNAMErecord. Additionally, each CNAME record includes additional information(e.g., “additional information”), such as request routing information,performance measurement information, and the like. An illustrative CNAMErecord can have the form of:

CNAME additional_information.cdnprovider.com

In an illustrative embodiment, the CNAME records are generated andprovided by the DNS servers to direct DNS queries to a different DNSserver of the CDN service provider 106. In one embodiment, thesubsequent DNS queries (corresponding to the CNAME) will be directed, orotherwise be received by, a different DNS server of the CDN serviceprovider 106. As will be explained in greater detail below, the CNAMEcan include additional request routing information that causes the DNSquery to be received by a different POP or otherwise cause thesubsequent DNS query to be forwarded to a DNS server at a different POP.In other embodiments, the subsequent DNS queries will be directed towardthe same DNS server that received the previous DNS query.

In some embodiments, the selection of different DNS servers to receiveone or more subsequent DNS queries may be based on a determinedappropriateness of other DNS servers to process DNS queries from aparticular client computing device 102 or set of client computingdevices. As used in accordance with the present disclosure,appropriateness can be defined in any manner by the CDN service provider106 for a variety of purposes. In one example, the CDN service provider106 can attempt to direct DNS queries to DNS servers, such as in thereturned CNAME, according to geographic criteria. The geographiccriteria can correspond to geographic-based regional service planscontracted between the CDN service-provider 106 and the content provider104 in which various CDN service provider 106 POPs are grouped intogeographic regions. Accordingly, a client computing device 102 DNS queryreceived in a region not corresponding to the content provider'sregional plan may be better processed by a DNS server in a regioncorresponding to the content provider's regional plan. In this example,the DNS server component 118 may also obtain geographic information fromthe client directly (such as information provided by the clientcomputing device or ISP) or indirectly (such as inferred through aclient computing device's IP address).

In another example, the CDN service provider 106 can attempt to directDNS queries to DNS servers according to service level criteria. Theservice level criteria can correspond to service or performance metricscontracted between the CDN service provider 106 and the content provider104. Examples of performance metrics can include latencies of datatransmission between the CDN service provider POPs and the clientcomputing devices 102, total data provided on behalf of the contentprovider 104 by the CDN service provider POPs, error rates for datatransmissions, and the like.

In still a further example, the CDN service provider 106 can attempt todirect DNS queries to DNS servers according to network performancecriteria. The network performance criteria can correspond tomeasurements of network performance for transmitting data from the CDNservice provider POPs to the client computing device 102. Examples ofnetwork performance metrics can include network data transfer latencies(measured by the client computing device or the CDN service provider106, network data error rates, and the like.

In accordance with an illustrative embodiment, the DNS server maintainsa data store that defines CNAME records for various original URLs. If aDNS query corresponding to a particular original URL matches an entry inthe data store, the receiving DNS server component 120 returns a CNAMErecord as defined in the data store. In an illustrative embodiment, thedata store can include multiple CNAME records corresponding to aparticular original URL. The multiple CNAME records would define a setof potential candidates that can be returned to the client computingdevice 102. In such an embodiment, the DNS server component 120, eitherdirectly or via a network-based service, can implement additional logicin selecting an appropriate CNAME from a set of possible of CNAMEs. Forexample, the DNS servers can have logic to determine which CNAME toreturn for purposes of testing different components or aspects of theCDN service provider 106. Examples of such different aspects can includetesting different software application platforms, testing differentsupported languages, testing different ISPs, and the like. In anillustrative embodiment, each DNS server component 120, 126 maintainsthe same data stores that define CNAME records, which can be managedcentrally by the CDN service provider 106. Alternatively, each DNSserver component 120, 126 can have POP specific data stores that defineCNAME records, which can be managed centrally by the CDN serviceprovider 106 or locally at the POP 118, 124.

The returned CNAME can also include request routing information that isdifferent from or in addition to the information provided in URL/CNAMEof the current DNS query. For example, if the CNAME selection is basedon regional plan, a specific regional plan can be identified in the“request_routing_information” portion of the specific CNAME record. Asimilar approach could be taken to identify service level plans and filemanagement by including a specific identifier in the“request_routing_information” portion of the CNAME record. In anotherembodiment, request routing information can be found in theidentification of a CDN service provider 106 domain different from thedomain found in the current URL/CNAME. For example, if the CNAME isbased on regional plan, a specific regional plan domain (e.g.,“cdnprovider-region1.com”) could be used in the domain name portion ofthe specific CNAME record. Any additional request routing informationcan be prepended to the existing request routing information in thecurrent URL/CNAME such that the previous request routing informationwould not be lost (e.g., serviceplan.regionalplan.cdnprovider.com). Oneskilled in the relevant art will appreciate that additional oralternative techniques and/or combination of techniques may be used toinclude the additional request routing information in the CNAME recordthat is selected by the DNS server component 120.

With reference now to FIG. 5, in an illustrative embodiment, the DNSresolver 108 obtains the CNAME, or other alternative identifier,provided by the receiving DNS server and processes the CNAME. In oneaspect, the DNS resolver 108 can process the return information to logor determine performance measurement information, such as a total timefrom the transmittal of the original DNS query. Additionally, inaccordance with network principles, the DNS resolver 108 then transmitsa DNS query corresponding to the returned CNAME. As previously discussedwith regard to FIG. 4, the DNS query process could first start with DNSqueries for the “.” and “com” portions, followed by a query for the“cdnserviceprovider” portion of the CNAME. To the extent, however, thatthe results of previous DNS queries can be cached (and remain valid),the DNS resolver 108 can utilize the cached information and does notneed to repeat the entire process. However, at some point, depending onwhether the CNAME provided by DNS server component 120 (FIG. 4) and theprevious URL/CNAME share common CDN service provider domains, resolvesto a different POP provided by the CDN service provider 106.

As illustrated in FIG. 5, the DNS server component 126 of POP 124 is nowauthoritative based on the different information in the current CNAMEpreviously provided by the DNS server component 120. As previouslydescribed, the DNS server component 126 can then determine whether toresolve the DNS query on the CNAME with an IP address of a cachecomponent that will process the content request or whether to provideanother alternative resource identifier selected in the manner describedabove. In an illustrative embodiment, the DNS server components canutilize a variety of information in selecting a resource cachecomponent. In one example, the DNS server component can default to aselection of a resource cache component of the same POP. In anotherexample, the DNS server components can select a resource cache componentbased on various load balancing or load sharing algorithms. Stillfurther, the DNS server components can utilize network performancemetrics or measurements to assign specific resource cache components.The IP address selected by a DNS server component may correspond to aspecific caching server in the resource cache. Alternatively, the IPaddress can correspond to a hardware/software selection component (suchas a load balancer).

Based on the processes illustrated in FIGS. 4 and 5, the CDN serviceprovider 106, DNS resolver 108 or other component can utilizeperformance measurement information for a variety of purposes. Forexample, the collected performance measurement information can beutilized to determine an ordered priority of POPs for a particular DNSresolver component 108 or sets of DNS resolver components. In anotherexample, the performance measurement information can be utilized toverify an existing prioritization of POPs for a particular DNS resolvercomponent 108 or sets of DNS resolver components. Still further, theperformance measurement information can be combined with otherinformation mapping client computing devices 102 with DNS resolvercomponents 108 to determine prioritized or optimized POPs for clientcomputing devices 102 or groups of client computing devices associatedwith one or more DNS resolvers 108.

With reference now to FIG. 6, in another embodiment to measureperformance measurement after the receipt of content including one ormore embedded identifiers (FIG. 3), the client computing device 102would first transmit a DNS query through its DNS resolver 108 to requestan IP address of a computing device corresponding to the uniqueidentifier provided by the CDN service provider 106. The DNS query wouldbe received by the DNS resolver 108 and then transmitted on behalf ofthe requesting client computing device 102.

As previously described with regard to FIG. 4, by way of example, inaccordance with traditional DNS request routing principles, a DNS queryfor the URL would first include the identification of a DNS serverauthoritative to the “.” and the “com” portions of the URL to the DNSresolver 108. The issuance of DNS queries corresponding to the “.” andthe “com” portions of a URL are well known and have not beenillustrated. After partially resolving the modified URL according to the“.” and “com” portions of the URL, the DNS resolver 108 then issuesanother DNS query for the resource URL that results in theidentification of the DNS server corresponding to the“.cdnserviceprovider” portion of the URL. Specifically, the successfulresolution of the “.cdnserviceprovider” portion of the original URLidentifies a network address, such as an IP address, of a DNS serverassociated with the CDN service provider 106. In this embodiment, the IPaddress can be shared by one or more POPs. Accordingly, the further DNSquery to the shared IP address utilizes a one-to-many network routingschema, such as anycast, such that a specific POP will receive therequest as a function of network topology. For example, in an anycastimplementation, a DNS query issued by a client computing device 102 to ashared IP address will arrive at a DNS server component logically havingthe shortest network topology distance, often referred to as networkhops, from the client computing device. The network topology distancedoes not necessarily correspond to geographic distance. However, in someembodiments, the network topology distance can be inferred to be theshortest network distance between a client computing device 102 and aPOP.

As previously discussed with regard to FIG. 4, the receiving DNS servercomponent 120 obtains the DNS query from the DNS resolver component 108and processes the DNS query. In an illustrative embodiment, the DNSserver component 120 determines that the processing of the DNS queryshould be, at least in part, used to measure performance of the DNSresolver 108 or other network component. In one embodiment, the DNSquery may not correspond to an actual resource that will be delivered tothe client computing device 102. Alternatively, the DNS query maycorrespond to an actual resource provided by the CDN service provider106 on behalf of the content provider 104. Illustratively, the“additional information” portion of the URL may include information thatwill be utilized to determine whether the CDN service provider 106should utilize the DNS query for performance measurement or whether itwill be utilized in the determination of the performance measurement.For example, a client computing device may execute a script prior to thegeneration of the DNS query that modifies the URL to include variousidentifiers or timing information in the URL.

To facilitate the performance measurement, the receiving POP, POP 118,can obtain information from the DNS query or collect additionalinformation. The collected information can be maintained in the DNSresolver log data store 130. One skilled in the relevant art willappreciate that, typically, a receiving DNS server can resolve DNSqueries by identifying an IP address of a cache server component, suchresource cache component 122, that will process the request for therequested resource. The selected resource cache component can processthe request by either providing the requested resource if it isavailable or attempting to obtain the requested resource from anothersource, such as a peer cache server computing device or the originserver 114 of the content provider 104. However, in this illustrativeembodiment, as an alternative to selecting a cache server component, theCDN service provider 106 can maintain sets of various alternativeresource identifiers that can be utilized for more refined requestrouting purposes. Additionally, in this embodiment, the alternativeresource identifiers can be utilized to measure the performance of theDNS resolver component 108 (or other network components). Specifically,the alternative resource identifiers can be provided by the CDN serviceprovider 106 to the client computing device 102 such that a subsequentDNS query on the alternative resource identifier will resolve to adifferent DNS server component within the CDN service provider'snetwork. As previously discussed, the alternative resource identifiercan correspond to a CNAME.

With reference now to FIG. 7, in an illustrative embodiment, the DNSresolver 108 obtains the CNAME, or other alternative identifier,provided by the receiving DNS server and processes the CNAME. In oneaspect, the DNS resolver 108 can process the return information to logor determine performance measurement information, such as a total timefrom the transmittal and processing of the original DNS query, availablebandwidth, packet loss, data throughput, etc. Additionally, inaccordance with network principles, the DNS resolver 108 then transmitsa DNS query corresponding to the returned CNAME. As previously discussedwith regard to FIG. 4, the DNS query process could first start with DNSqueries for the “.” and “com” portions, followed by a query for the“.cdnserviceprovider” portion of the CNAME. To the extent, however, thatthe results of a previous DNS queries can be cached (and remain valid),the DNS resolver 108 can utilize the cached information and does notneed to repeat the entire process. However, in this embodiment, at somepoint, the DNS resolver 108 transmits a DNS query for the“.cdnserviceprovider” utilizing a different network routing schema.Specifically, in an illustrative embodiment, the further DNS query to ashared IP address or unique IP address utilizes a one-to-one networkrouting schema, such as unicast, such that a specific POP will receivethe DNS query.

In this embodiment, the CNAME is selected such that the subsequent DNSquery will be received by the same POP utilizing the different networkrouting schema. Examples of different routing schemas can include theutilization of different communication protocols, such as anycast andunicast. In other examples, the routing schema can include thespecification of different communication network paths or theutilization of different ISPs. For example, the IP address of the DNSservers of the CDN service provider may be selected such that the firstand second DNS queries (and possibly additional DNS queries) may betransmitted via different communication network ISPs. In anotherexample, a communication protocol, such as the Border Gateway Protocol,can be manipulated to facilitate the transmission of DNS queries alongdifferent communication network paths. As illustrated in FIG. 7, the DNSserver component 120 of POP 118 is again authoritative based on theinformation in the current CNAME previously provided by the DNS servercomponent 118. As previously described, the DNS server component 120 canthen determine whether to resolve the DNS query on the CNAME with an IPaddress of a cache component that will process the content request orwhether to provide another alternative resource identifier selected inthe manner described above. In an illustrative embodiment, the DNSserver components can utilize a variety of information in selecting aresource cache component. In one example, the DNS server component candefault to a selection of a resource cache component of the same POP. Inanother example, the DNS server components can select a resource cachecomponent based on various load balancing or load sharing algorithms.Still further, the DNS server components can utilize network performancemetrics or measurements to assign specific resource cache components.The IP address selected by a DNS server component may correspond to aspecific caching server in the resource cache. Alternatively, the IPaddress can correspond to a hardware/software selection component (suchas a load balancer).

With reference now to FIG. 8, in an alternative to the embodimentillustrated in FIG. 7, the CNAME is selected such that the subsequentDNS query will be received by a different POP utilizing the differentnetwork routing schema. Accordingly, as illustrated in FIG. 8, the DNSserver component 126 of POP 124 is now authoritative based on thedifferent information in the current CNAME previously provided by theDNS server component 120. As previously described, the DNS servercomponent 126 can then determine whether to resolve the DNS query on theCNAME with an IP address of a cache component that will process thecontent request or whether to provide another alternative resourceidentifier selected in the manner described above. In an illustrativeembodiment, the DNS server components can utilize a variety ofinformation in selecting a resource cache component. In one example, theDNS server components can default to a selection of a resource cachecomponent of the same POP. In another example, the DNS server componentscan select a resource cache component based on various load balancing orload sharing algorithms. Still further, the DNS server components canutilize network performance metrics or measurements to assign specificresource cache components. The IP address selected by a DNS servercomponent may correspond to a specific caching server in the resourcecache. Alternatively, the IP address can correspond to ahardware/software selection component (such as a load balancer).

Based on the processes illustrated in FIGS. 6, 7 and 8, the CDN serviceprovider, DNS resolver 108 or other component can utilize performancemeasurement information for a variety of purposes. For example, thecollected performance measurement information can be utilized todetermine an ordered priority of routing schemas utilized to accessparticular POPs. In another example, the performance measurementinformation can be utilized to verify an existing prioritization of POPsfor a particular DNS resolver component 108 or sets of DNS resolvercomponents. Still further, the performance measurement information canbe combined with other information mapping client computing devices 102with DNS resolver components 108 to determine prioritized or optimizedPOPs for client computing devices 102 or groups of client computingdevices associated with one or more DNS resolvers 108.

With reference now to FIG. 9, a request routing processing routine 900implemented by the CDN service provider 106 will be described. Oneskilled in the relevant art will appreciate that actions/steps outlinedfor routine 900 may be implemented by one or many computingdevices/components that are associated with the CDN service provider106. Accordingly, routine 900 has been logically associated as beingperformed by the CDN service provider 106.

At block 902, one of the DNS server components 120, 126 obtains a DNSquery corresponding to resource identifier (the “receiving DNS server”).As previously discussed, the resource identifier can be a URL that hasbeen embedded in content requested by the client computing device 102and previously provided by the content provider 104. Alternatively, theresource identifier can also correspond to a CNAME provided by a contentprovider DNS server in response to a DNS query previously received fromthe client computing device 102. At block 904, the receiving DNS serverobtains DNS resolver 108 identification information from the DNS query,such as an IP address or other identifier.

At decision block 906, a test is conducted to determine whether thecurrent DNS server is authoritative to resolve the DNS query. In oneillustrative embodiment, the DNS server can determine whether it isauthoritative to resolve the DNS query if there are no CNAME recordscorresponding to the received resource identifier (e.g., no additionalperformance measurement will take place).

If the current DNS server is authoritative (including a determinationthat the same DNS server will be authoritative for subsequent DNSqueries), the current DNS server resolves the DNS query by returning theIP address of a cache server component at block 908. In a non-limitingmanner, a number of methodologies for selecting an appropriate resourcecache component have been previously discussed. Additionally, asdescribed above, the IP address may correspond to a specific cacheserver of a resource cache component or generally to group of cacheservers.

Alternatively, if at decision block 906, the DNS server is notauthoritative, at block 910, the DNS server component selects andtransmits an alternative resource identifier. As described above, theDNS server component can utilize a data store to identify an appropriateCNAME as a function of the current DNS query. Additionally, the DNSserver component can also implement additional logical processing toselect from a set of potential CNAMES. As previously described, in oneembodiment, the CNAME may be selected to direct the DNS resolver 108 toa different POP. In another embodiment, the CNAME may be selected todirect the DNS resolver 108 to utilize a different request routingschema, regardless of whether the subsequent CNAME DNS query is directedto the same or different DNS server. At block 912, different DNS servercomponents receive a DNS query corresponding to the CNAME. The routine900 then returns to decision block 906 and continues to repeat asappropriate.

It will be appreciated by one skilled in the relevant art that there area number of ways to modify the routing information associated withrequests from a class of client computing devices. It will further beappreciated by one skilled in the relevant art that the timing at whichperformance is monitored and updates to routing information are made canvary.

It will be appreciated by those skilled in the art and others that allof the functions described in this disclosure may be embodied insoftware executed by one or more processors of the disclosed componentsand mobile communication devices. The software may be persistentlystored in any type of non-volatile storage.

Conditional language, such as, among others, “can,” “could,” “might,” or“may,” unless specifically stated otherwise, or otherwise understoodwithin the context as used, is generally intended to convey that certainembodiments include, while other embodiments do not include, certainfeatures, elements and/or steps. Thus, such conditional language is notgenerally intended to imply that features, elements and/or steps are inany way required for one or more embodiments or that one or moreembodiments necessarily include logic for deciding, with or without userinput or prompting, whether these features, elements and/or steps areincluded or are to be performed in any particular embodiment.

Any process descriptions, elements, or blocks in the flow diagramsdescribed herein and/or depicted in the attached figures should beunderstood as potentially representing modules, segments, or portions ofcode which include one or more executable instructions for implementingspecific logical functions or steps in the process. Alternateimplementations are included within the scope of the embodimentsdescribed herein in which elements or functions may be deleted, executedout of order from that shown or discussed, including substantiallyconcurrently or in reverse order, depending on the functionalityinvolved, as would be understood by those skilled in the art. It willfurther be appreciated that the data and/or components described abovemay be stored on a computer-readable medium and loaded into memory ofthe computing device using a drive mechanism associated with acomputer-readable medium storing the computer executable components suchas a CD-ROM, DVD-ROM, or network interface; further, the componentand/or data can be included in a single device or distributed in anymanner. Accordingly, general purpose computing devices may be configuredto implement the processes, algorithms and methodology of the presentdisclosure with the processing and/or execution of the various dataand/or components described above.

It should be emphasized that many variations and modifications may bemade to the above-described embodiments, the elements of which are to beunderstood as being among other acceptable examples. All suchmodifications and variations are intended to be included herein withinthe scope of this disclosure and protected by the following claims.

What is claimed is:
 1. A computer-implemented system comprising: a data store for storing performance monitoring information associated with network components associated with client computing device requests for content; and a computing system in communication with said data store and associated with a service provider, the computing system including a hardware component and operative to: obtain a first domain name service (DNS) query responsive to at least one resource identifier, the first DNS query corresponding to a resource associated with the resource identifier, and the first DNS query being provided in accordance with a first network scheme; determine an alternative identifier responsive to the first DNS query, the alternative identifier to cause a second DNS query associated with the resource to be transmitted to a component associated with the service provider utilizing a second network scheme; and determine an ordered priority of network schemes to use to access particular components associated with the service provider, the determination of the ordered priority being based on performance information associated with the first and second DNS queries.
 2. The system as recited in claim 1, wherein the computing system including the hardware component is further operative to: verify an existing prioritization of components associated with the service provider for servicing requests, the verification of the existing prioritization being based on performance information associated with the first and second DNS queries.
 3. The system as recited in claim 1, wherein the resource identifier corresponds to a uniform resource locator of the service provider.
 4. The system as recited in claim 1, wherein the alternative identifier references a domain different from a domain associated with the resource identifier.
 5. The system as recited in claim 1, wherein the first DNS query is transmitted in accordance with an anycast network scheme.
 6. The system as recited in claim 1, wherein the second DNS query is transmitted in accordance with a unicast network scheme.
 7. The system as recited in claim 1, wherein the hardware component corresponds to a DNS resolver component.
 8. The system as recited in claim 1, wherein the first network scheme corresponds to a first network path and the second network scheme corresponds to a second network path.
 9. The system as recited in claim 1, wherein the first and second DNS queries are obtained by different network components.
 10. A computer-implemented method comprising: obtaining, by a service provider, a first domain name service (DNS) query responsive to at least one resource identifier, the first DNS query corresponding to a resource associated with the resource identifier, and the first DNS query being provided in accordance with a first network scheme; determining, by the service provider, an alternative identifier responsive to the first DNS query, the alternative identifier to cause a second DNS query associated with the resource to be transmitted to a component associated with the service provider utilizing a second network scheme; and determining a priority of network schemes for accessing components associated with the service provider, the determination of the priority being based at least in part on performance information associated with the first and second DNS queries.
 11. The method as recited in claim 10 further comprising verifying an existing prioritization of components associated with the service provider for servicing requests, the verification of the existing prioritization being based on performance information associated with the first and second DNS queries.
 12. The method as recited in claim 10, wherein the resource identifier corresponds to a uniform resource locator of the service provider.
 13. The method as recited in claim 10, wherein the alternative identifier references a domain different from a domain associated with the resource identifier.
 14. The method as recited in claim 10, wherein the alternative identifier includes a label representative of request routing information identifying the component associated with the service provider.
 15. The method as recited in claim 10, wherein the alternative identifier further includes a label representative of additional information associated with the client computing device.
 16. The method as recited in claim 10, wherein the first DNS query is transmitted in accordance with an anycast network scheme.
 17. The method as recited in claim 10, wherein the second DNS query is transmitted in accordance with a unicast network scheme.
 18. The method as recited in claim 10, wherein the first DNS query is obtained by a DNS resolver component of the service provider.
 19. The method as recited in claim 10, wherein the first network routing scheme corresponds to a first network path and the second network routing scheme corresponds to a second network path.
 20. The method as recited in claim 10, wherein the first and second DNS queries are obtained by different network components. 